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Abstract 

Sensor  networks,  a  novel  paradigm  in  distributed  wireless  communication  technology,  have  been  proposed 
for  use  in  various  applications  including  military  surveillance  and  environmental  monitoring.  These  systems 
could  deploy  heterogeneous  collections  of  sensors  capable  of  observing  and  reporting  on  various  dynamic 
properties  of  their  surroundings  in  a  time  sensitive  manner.  Such  systems  suffer  bandwidth,  energy,  and 
throughput  constraints  that  limit  the  quantity  of  information  transferred  from  end  to  end.  These  factors  cou¬ 
pled  with  unpredictable  traffic  patterns  and  dynamic  network  topologies  make  the  task  of  designing  optimal 
protocols  for  such  networks  difficult.  Mechanisms  to  perform  data  centric  aggregation  utilizing  application 
specific  knowledge  provide  a  means  to  augmenting  throughput,  but  have  limitations  due  to  their  lack  of  adap¬ 
tation  and  reliance  on  application  specific  decisions.  We  therefore  propose  a  novel  aggregation  scheme  that 
adaptively  performs  application  independent  data  aggregation  in  a  time  sensitive  manner.  Our  work  isolates 
aggregation  decisions  into  a  module  that  resides  between  the  network  and  the  data  link  layer  and  does  not 
require  any  modifications  to  the  currently  existing  MAC  and  network  layer  protocols.  We  take  advantage  of 
queuing  delay  and  the  broadcast  nature  of  wireless  communication  to  concatenate  network  units  into  an  ag¬ 
gregate  using  a  novel  adaptive  feedback  scheme  to  schedule  the  delivery  of  this  aggregate  to  the  MAC  layer 
for  transmission.  In  our  evaluation  we  show  that  end-to-end  transmission  delay  is  reduced  by  as  much  as  80% 
under  heavy  traffic  loads.  Additionally,  we  show  as  much  as  a  50%  reduction  in  transmission  energy  con¬ 
sumption  with  cm  overall  negative  header  overhead.  Theoretical  analysis,  simulation,  and  a  test-bed  imple¬ 
mentation  on  Berkeley’s  MICA  motes  are  provided  to  validate  our  claims. 

1.  Introduction 

Wireless  Sensor  Networks  have  emerged  as  a  new  information-gathering  paradigm  based  on  the  collabora¬ 
tive  effort  of  a  large  number  of  sensing  nodes.  In  such  networks,  nodes  deployed  in  a  remote  environment 
must  self-configure  without  any  a  priori  information  about  the  network  topology  or  global  view.  Nodes  will 
act  in  response  to  environmental  events  and  relay  collected  and  possibly  aggregated  information  through  the 
formed  multi-hop  wireless  network  in  accordance  with  desired  system  functionality.  The  inherently  dynamic 
and  distributed  behavior  of  these  networks,  coupled  with  inherent  physical  limitations  such  as  small  instruction 
and  data  memory,  constrained  energy  resources,  short  communication  radii,  and  a  low  bandwidth  medium  in 
which  to  communicate,  make  developing  communication  protocols  difficult. 

Research  on  hardware  for  such  devices  has  taken  place  at  Berkeley  [14]  [32]  [34]  and  various  other  research 
institutions  [26]  throughout  the  world.  Using  such  hardware  as  a  basis  for  development,  the  software  architec¬ 
ture  and  communication  stack  residing  on  these  devices  are  built  taking  into  consideration  the  prolific  research 
in  the  areas  of  ad-hoc  networking  [10][15][17] [20],  data  aggregation  [16][21][28],  cluster  formation  [27],  dis¬ 
tributed  services  [22],  group  formation  [6],  channel  contention  [3]  [5]  [7]  [19],  and  power  conservation  [4]  [12], 
Work  targeted  to  these  devices  include  research  in  query  processing  (e.g.  TinyDB  [25]),  and  aggregation  (e.g. 
TAG  [24]).  Work  on  the  utility  of  such  innovative  technologies  has  unearthed  potential  applications  includ¬ 
ing,  event  tracking  [1],  environmental  monitoring,  disaster  relief,  and  search  and  rescue. 

In  this  work,  we  address  the  problems  of  low  bandwidth  and  energy  limitations  inherent  to  sensor  devices. 
These  networks’  ever-changing  and  unpredictable  state  demands  a  self-configuring,  adaptive  solution.  We 
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develop  a  novel  adaptive  application  independent  data  aggregation  (AIDA)  component  that  fits  seamlessly  into 
current  sensor  network  communication  stack.  Our  goal  is  to  maximize  utilization  of  the  communication  chan¬ 
nel  (single  frequency)  with  energy  savings  coming  as  an  ancillary  benefit.  With  significant  costs  incurred 
from  channel  contention,  packet  header  overhead,  and  data  padding  for  fixed  sized  packets,  this  work  abates 
such  costs  by  employing  varying  degrees  of  data  aggregation  at  forwarding  nodes  in  accordance  with  current 
local  traffic  patterns. 

Data  aggregation  techniques  have  been  extensively  investigated  in  recent  literature.  Our  work,  as  a  novel 
data  aggregation  approach,  distinguishes  itself  from  current  state  of  the  art  solutions  in  three  respects.  First, 
prior  Application  Dependent  Data  Aggregation  (ADDA  shown  in  Figure  lb)  relies  on  application  layer  infor¬ 
mation  and  must  have  a  bi-directional  interface,  and  therefore  dependence  with,  the  data  centric  routing 
protocol  implemented.  AIDA  isolates  aggregation  decisions  from  application  specifics  by  performing  adaptive 
aggregation  in  an  intermediate  layer  that  resides  between  the  traditional  data-link  and  network  layer  protocols 
(Figure  l.a).  This  component  is  generalized  enough  to  be  utilized  over  a  wide  range  of  applications  (data  types) 
without  incurring  the  costs  of  rewriting  components  to  support  application-specific  logics.  Second,  no  prior 
work  in  data  aggregation  adapts  itself  to  the  traffic  situation  in  a  time  sensitive  manner.  AIDA  takes  the  timely 
delivery  of  messages  as  well  as  protocol  overhead  into  account  to  adaptively  adjust  aggregation  strategies  in 
accordance  with  assessed  traffic  conditions  and  expected  sensor  network  requirements.  Simulation  results 
show  that  AIDA  can  adapt  to  varying  traffic  situations  and  dramatically  reduce  network  congestion  and  trans¬ 
mission  energy  consumption.  Third,  previous  data  aggregation  schemes  (e.g.,  data  centric  routing  [16])  per¬ 
form  in-network  processing  to  reduce  the  amount  of  application  data  transmitted.  These  in-network  processes 
(e.g.  averaging)  can  achieve  higher  degrees  of  aggregation;  however  data  are  less  available  to  the  application 
(e.g.  standard  deviation  of  the  data  set  can  not  obtained  from  the  average).  In  contrast,  AIDA  performs  loss¬ 
less  aggregation  allowing  the  upper  layer  to  decide  whether  information  compression  is  appropriate  at  the  time. 
Very  important,  our  design  enables  AIDA  to  remain  complementary  to  other  data  aggregation  strategies 
(Figure  l.c)  while  providing  significant  timesaving  benefits  in  the  lower  layers  of  the  communication  stack. 
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Figure  1 :  Architectural  Designs 

This  paper  attempts  to  address  the  aforementioned  problems  through  a  novel  adaptive  time  sensitive  data 
aggregation  component.  As  an  introduction  to  sensor  networks,  and  to  provide  a  more  in  depth  discussion  of 
the  type  of  research  taking  place  within  this  field,  we  begin  section  2  with  a  discussion  of  related  and  ongoing 
work.  Section  3  addresses  the  need  for  adaptation,  data  aggregation,  and  real-time  data  delivery.  Section  4 
then  presents  specific  details  about  our  protocol.  Sections  5  and  6  describe  our  simulation  environment,  the 
type  of  experiments  run,  and  a  discussion  of  the  results  we  obtain  in  both  simulation  and  in  the  Berkeley 
MICA  test-bed.  Finally,  we  conclude  in  Section  7. 

2.  Leveraging  Previous  Work 

Efforts  to  maximize  channel  utilization  have  been  spread  across  various  layers  of  the  sensor  network 
communication  stack.  Stalling  at  the  MAC  layer,  these  include  attempts  to  minimize  collisions  through  con¬ 
tention-based  mechanisms  designed  for  a  lossy  wireless  medium.  Such  work  includes  802.1 1  [3],  MACA  [19], 
MACAW  [5],  FAMA[7],  S-MAC[31],  and  Multi-Hop  Scheduling  [18],  to  name  a  few.  All  of  these  solutions 
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reside  within  the  data-link  layer  of  the  communication  stack  and,  therefore,  can  coexist  with  the  higher  layer 
aggregation  component  we  provide. 

Similar  to  the  data  link  layer  the  network  layer,  and  more  specifically  the  routing  component,  has  brought 
about  significant  efforts  to  avoid  congestion  and  maximize  use  of  the  communication  medium.  Such  schemes 
include  distributing  the  traffic  load  to  route  around  congestion  [10]  and  using  a  minimal  hop  path  to  reduce  the 
total  number  of  transmissions  [29].  Beyond  the  routing  layer  the  communication  stack  in  sensor  networks  be¬ 
comes  more  amorphous.  Clustering  [27],  group  formation  [6],  and  other  higher  layer  hierarchical  components 
serve  to  combine  node  responsibilities  and  come  to  consensus  on  what  data  to  send.  Often  such  information  is 
application  specific  and  must  rely  on  a  general  understanding  of  exactly  what  the  network  is  tasked  to  do.  Ad¬ 
ditionally,  the  hierarchical  and  grouping  components  often  utilize  various  forms  of  data  aggregation  through 
consensus  algorithms  or  other  forms  of  local  processing. 

Basic  schemes  [16]  for  the  aggregation  of  data  include  the  Center  at  the  Nearest  Source  (CNS),  where  data 
is  aggregated  at  the  source  nearest  to  the  destination;  Shortest  Path  Trees  (SPT),  where  data  is  sent  along  the 
shortest  path  from  source  to  sink  and  aggregated  at  common  intermediate  hops  along  the  way;  and  Greedy  In¬ 
cremental  Trees  (GIT),  which  builds  an  aggregation  tree  sequentially  to  merge  paths  and  provide  more  aggre¬ 
gation  opportunities. 

Expressing  queries  [25]  and  utilizing  those  queries  for  data  aggregation  [24]  present  opportunities  for  in 
network  data  aggregation.  An  extremely  popular  data  aggregation  scheme  for  sensor  networks,  Directed  Dif¬ 
fusion  [15]  [11],  is  a  data-centric  architecture  where  named  (application  specific)  data  gets  propagated  along 
paths  back  to  the  requestor.  Effective  paths  are  reinforced  as  they  are  used  to  optimize  communication  from 
point  to  point.  Specifically  designed  for  sensor  networks,  Directed  Diffusion  aggregates  data  along  these  rein¬ 
forced  paths  to  reduce  the  quantity  of  data  transmitted  across  the  network.  Similarly  Data  Placement  [28]  is 
designed  for  applications  where  multiple  sinks  coexist  and  use  in-network  caching  to  update  and  distribute 
data  to  leaf  nodes  at  the  minimally  requested  rate.  LEACH  [12]  is  a  high  layer  protocol  that  provides  cluster¬ 
ing  and  local  processing  to  aggregate  sensor  data  and  reduce  global  communication.  Many  other  data  aggrega¬ 
tion  schemes  exist  that  also  provide  network,  transport,  and  application  level  mechanisms  taking  advantage  of 
application  specific  knowledge  about  the  data  in  question.  All  of  these  schemes  reside  either  at  or  above  the 
network  layer  and  are  orthogonal  and  can  coexist  with  our  work. 

Aggregation  scheme  comparison  studies  have  demonstrated  the  effect  of  network  parameters  and  the  util¬ 
ity  of  aggregation  mechanisms  in  a  wide  variety  of  applications  [16] [21],  These  studies  discuss  potential  sav¬ 
ings  that  aggregation  can  provide  and  are  noted  to  explicate  the  potential  for  such  work  to  improve  network 
throughput. 

To  date,  very  few  sensor  network  papers  have  addressed  the  need  for  incorporating  adaptive  behavior  into 
their  protocols.  Sensor  networks  exhibit  complex  distributed  behavior  rendering  static  pre -configuration  ut¬ 
terly  useless  as  network  traffic,  often  initiated  by  environmental  events  of  interest,  transitions  from  one  ex¬ 
treme  to  another.  Several  protocols  have  taken  a  first  stab  at  addressing  the  need  for  adaptive  behavior  in  such 
dynamic  networks.  RAP  [23]  and  SPEED  [10]  utilize  locally  available  information  to  adjust  priority  levels  or 
make  more  informed  routing  decisions  in  response  to  network  congestion  and  changing  traffic  patterns.  SPIN 
[13]  makes  adaptive  decisions  to  participate  in  data  dissemination  based  on  current  energy  levels  and  the  cost 
of  communication.  In  [32],  A.  Woo  uses  adaptive  rate  control  at  the  data-link  layer  to  fine  tune  contention  pa¬ 
rameters  in  response  to  local  traffic  conditions.  GAF  [30]  monitors  network  connectivity  and  turns  nodes 
on/off  to  adapt  network  density  for  energy-conservation.  While  many  more  examples  of  online  adaptation 
exist,  these  solutions  provide  relevant  examples  of  how  adaptation  is  beneficial  in  dynamic  and  unpredictable 
sensor  networks  and  serve  as  a  stalling  point  to  introduce  adaptive  behavior  into  these  complex  systems. 

In  addition  to  maximizing  channel  utilization  and  adapting  to  dynamic  network  conditions,  energy  conser¬ 
vation  has  become  a  central  focus  in  sensor  network  research.  Similar  to  data  aggregation,  work  in  energy 
conservation  for  sensor  networks  has  been  considered  at  various  levels  of  the  communication  stack.  Aside 
from  minimizing  power  consumption  at  the  hardware  level  [26],  MAC  layer  protocols  developed  for  energy 
savings  mostly  take  advantage  of  overhearing  and  scheduling  to  allow  nodes  to  sleep  while  they  are  not  trans¬ 
mitting  or  receiving  messages  [8]  [12]  [29] .  At  the  network  and  routing  layers,  schemes  work  to  minimize 
power  along  the  transmission  path  [28],  set  routes  according  to  the  energy  remaining  at  nodes  along  that  path 
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[33],  and  use  mechanisms  to  save  power  through  the  distribution  of  messages  among  various  paths  from 
source  to  destination  [10].  Finally,  higher  layer  protocols  that  often  incorporate  routing  semantics  exist  to 
form  groups  and  rotate  leadership  responsibilities  allowing  non-leader  nodes  to  sleep  and  conserve  their  en¬ 
ergy  [4],  Again  all  of  these  protocols  involve  layered  decisions  that  should  adhere  to  strict  modular  program¬ 
ming  interfaces  allowing  our  work  to  coexist  with  them. 

3.  Analysis  of  the  Problem 

Various  studies  of  throughput  and  channel  utilization  for  wireless  ad  hoc  networks  have  identified  the  lim¬ 
its  of  sensor  networks  due  to  asymmetric  channels,  multi-hop  interference,  high  traffic  density,  and  unpredict¬ 
able  communication  patterns.  To  minimize  such  problems,  mechanisms  for  contention  have  been  introduced  to 
notify  neighbors  of  a  node’s  intention  to  send  a  message.  While  such  mechanisms  have  proven  effective  in 
minimizing  collisions  and,  therefore,  make  better  use  of  the  channel,  the  overhead  involved  in  sending  control 
messages  remains  significant.  Aside  from  control  overhead  incurred  during  handshake,  additional  idle  time  is 
spent  listening  to  the  channel  and  backing  off  to  determine  when  it  is  appropriate  to  initiate  channel  contention. 
Such  properties  create  ample  opportunity  for  improvement. 

If  it  is  possible  to  reduce  the  number  of  control  messages  sent  while  still  distributing  information  about  a 
node’s  communication  intentions,  it  would  save  significant  time  and  energy  by  reducing  the  total  number  of 
messages  and  time  spent  contending  for  the  channel.  One  mechanism  for  achieving  such  a  feat  is  through  ap¬ 
plication  dependent  data  aggregation  (ADDA).  The  merging  of  data  that  maintain  common  properties  (seman¬ 
tics)  and  are  destined  for  the  same  node  has  been  a  common  approach  to  reducing  traffic.  While  such 
mechanisms  have  proven  effective  in  reducing  traffic  and  easing  congestion,  several  issues  that  limit  the  extent 
to  which  they  are  evolvable  provide  us  with  insight  into  developing  an  application  independent  aggregation 
(AIDA)  mechanism. 

■  Due  to  the  nature  of  application  specific  aggregation,  such  mechanisms  require  the  appropriate  naming 
of  data  and  require  that  lower  level  protocols  performing  such  aggregation  have  knowledge  and  logic 
to  support  these  naming  semantics.  As  a  result,  in  an  application  specific  aggregation  scheme,  the 
logic  of  the  components  will  need  to  be  changed  every  time  the  operation  or  task  changes.  For  exam¬ 
ple,  different  aggregation  logic  may  be  needed  for  mapping,  counting,  averaging,  standard  deviation, 
etc.  The  more  operations  the  applications  have  the  more  specific  the  aggregation  logic  needs  to  be, 
leading  to  time  consuming  modifications  and  a  cumbersome  design.  AIDA  seeks  a  solution  without 
such  cross-layer  dependencies  in  order  to  be  utilized  over  a  wide  range  of  data  types  and  applications 
without  incurring  the  costs  of  rewriting  components.  This  reduction  of  inter-layer  dependencies  leads 
to  a  lower  cost  to  system  evolvability. 

■  Pervious  aggregation  schemes  combine  application  specific  data  through  consensus  algorithms,  aver¬ 
aging  functions,  or  by  some  other  mathematical  manipulation  of  data,  resulting  in  a  loss  of  information. 
Because  such  schemes  bind  algorithms  to  the  application  and  make  it  difficult  to  control  the  degree  of 
information  loss  we  seek  a  solution  that  performs  lossless  aggregation  in  a  more  general  context. 

■  The  sensor  networks  we  envision  will  be  multi-purpose  systems.  These  systems  should  therefore  sup¬ 
port  aggregation  across  different  data  types.  An  ADDA  scheme  will  be  limited  and  somewhat  ineffec¬ 
tual  as  it  is  hard  to  aggregate  temperature  readings  with  light  readings  in  an  application  specific  way. 
We  desire  a  solution  that  allows  us  to  aggregate  traffic  originating  at  various  application  protocols 
without  any  knowledge  of  the  application  that  generated  this  data. 

■  To  properly  aggregate  named  data  from  a  common  source,  one  must  associate  both  location  and  time 
to  that  data  to  ensure  that  information  is  not  lost  or  inappropriately  merged.  For  example,  reports  on 
temperature  from  the  northeast  corner  of  a  network  should  not  be  combined  with  temperature  reports 
from  the  southwest  corner  just  because  they  share  a  common  type.  Any  aggregation  performed  must 
therefore  be  time  and  direction  sensitive  to  ensure  that  data  received  at  the  requester  remains  meaning¬ 
ful. 


4 


ACM  Transaction  on  Embedded  Computing  System 


■  Current  aggregation  schemes  assume  that  more  aggregation  is  always  better.  As  sensor  network  traf¬ 
fic  changes,  there  exist  times  when  varying  degrees  of  aggregation  are  necessary  to  optimize  commu¬ 
nication  and  augment  throughput.  However  at  other  times  aggregation  simply  acts  to  delay  data 
transmission.  AIDA  utilizes  feedback  control  based  on  network  traffic  conditions  when  making  ag¬ 
gregation  decisions  to  adaptively  optimize  bandwidth  while  minimizing  system  energy  consumption, 
which  is  underexploited  by  pervious  schemes  [16]  [21]  [24]  [25]  [28] 

Application  dependent  data  aggregation  (ADDA)  schemes  have  proven  to  be  effective  solutions  for  sensor 
networks.  Given  the  research  issues  underexploited  by  such  schemes,  we  seek  a  value-added  solution  that 
adapts  to  changing  network  conditions,  improves  the  networks  use  of  bandwidth,  is  simple  and  fast,  has  lim¬ 
ited  overhead,  performs  aggregation  without  loss  of  information,  and  considers  the  timeliness  of  end-to-end 
traffic.  In  addition,  we  require  a  solution  that  performs  aggregation  transparent  to  other  components.  This  will 
allow  AIDA  to  work  with,  or  exist  independently  of,  other  communication  protocols  so  that  AIDA  can  lever¬ 
age  the  performance  and  maintain  the  benefit  inherent  to  existing  ADDA  schemes. 

4.  Protocol  Design 

Our  solution  is  an  aggregation  layer  module  that  resides  between  the  data-link  and  networking  layer  to  ag¬ 
gregate  packets  through  network  unit  concatenation.  The  aggregation  component  combines  network  units  into 
a  single  outgoing  AIDA  payload  to  reduce  the  overhead  incurred  during  channel  contention  and  acknowledg¬ 
ment.  No  semantics  of  the  data  in  the  network  units  are  used.  Aggregation  decisions  are  made  in  accordance 
with  an  adaptive  feedback-based  packet-scheduling  scheme  that  dynamically  controls  the  degree  of  aggrega¬ 
tion  in  accordance  with  changing  traffic  conditions. 

4.1.  AIDA  Architecture  Design 

The  basic  design  of  AIDA  is  shown  in  Figure  2.  We  separate  AIDA  functionality  into  two  components. 
One  is  the  functional  unit  that  aggregates  and  de-aggregates  network  packets  (units).  The  other  is  the  AIDA 
Aggregation  Control  Unit,  employed  to  adaptively  control  timer  settings  and  fine-tune  the  desired  degree  of 
aggregation. 


Figure  2:  AIDA  Components 

The  protocol  works  as  follows:  Packets  from  the  network  layer  are  placed  into  an  aggregation  pool.  Ac¬ 
cording  to  the  number  of  packets  to  be  concatenated  in  one  aggregate  and  the  next-hop  destinations  of  those 
packets,  AIDA’s  Aggregation  Function  Unit  chooses  one  of  four  AIDA  packet  formats  (Described  in  depth  in 
section  4.3)  to  build  an  aggregate  and  passes  this  aggregate  down  to  the  MAC  layer  for  transmission.  The  de¬ 
cision  of  how  many  packets  to  aggregate  and  when  to  invoke  such  aggregation  is  left  up  to  the  AIDA  Aggre- 
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gation  Control  Unit,  a  feedback  based  adaptive  component  which  makes  on-line  decisions  based  on  local  cur¬ 
rent  network  conditions. 

Similar  to  outgoing  traffic,  incoming  traffic  is  received  at  the  MAC  layer  and  passed  up  to  AIDA.  Within 
AIDA  the  incoming  aggregates  are  re -fragmented  into  their  original  network  units  of  which  each  piece  of  the 
aggregate  is  passed  up  to  the  network  layer  for  re-routing  or  application  de-multiplexing  and  delivery.  Al¬ 
though  we  acknowledge  that  many  aggregates  may  be  bound  for  the  same  ultimate  destination  (it  could  be 
more  efficient  not  to  de-aggregate  and  re-aggregate  at  every  intermediate  node),  we  perform  such  de¬ 
aggregation  to  ensure  the  modularity  of  layers  and  allow  the  networking  component  to  determinate  routes  in¬ 
dependently  for  each  network  unit. 

The  aggregation  of  multiple  network  units  into  a  single  AIDA  aggregate  for  transmission  reduces  the 
overhead  of  channel  contention  (wait/backoff)  and  the  transmission  overhead  of  control  packets  (such  as 
RTS/CTS/ACK  in  802.11  [3],  RTS/CTS  in  MACAW  [5],  ACK  in  regular  reliable  MAC)  so  that  these  costs 
are  incurred  once  per  aggregate.  By  increasing  the  number  of  network  units  combined  into  a  single  AIDA  ag¬ 
gregate  (referred  to  as  the  degree  of  aggregation  [DOA]),  we  are  able  to  save  [DOA  -  1]  *  [contention  time] 
msec  on  each  transmission. 

While  the  aforementioned  AIDA  function  unit  is  straightforward,  it  is  an  intricate  research  problem  to  de¬ 
sign  an  adaptive  AIDA  control  unit  to  set  appropriate  timing  and  DOA  parameters  online.  As  we  show  in  our 
evaluation  section,  different  control  schemes  do  have  a  huge  impact  on  system  performance.  More  detail  on 
these  control  schemes  are  provided  and  discussed  in  section  4.2. 


Figure  3:  AIDA  Implementation  Design 

To  keep  AIDA  transparent  from  other  protocol  layers,  we  use  a  delegation  approach  to  intercept  all  func¬ 
tion  calls  between  the  MAC  and  Network  layer.  The  networking  component  assumes  it  is  talking  directly  to 
the  MAC  layer  and  vice  versa.  Using  this  method,  our  data  aggregation  layer  imitates  the  interfaces  exposed 
by  both  the  MAC  and  Networking  layer.  The  stack  resulting  from  this  technique  appears  in  Figure  3. 

4.2.  Aggregation  Schemes  in  AIDA  control  Unit 

To  better  understand  the  effect  of  aggregation  and  our  success  in  building  an  adaptive  solution,  we  design, 
implement,  test,  and  compare  several  versions  of  AIDA.  Versions  of  our  architecture  include  the  FIX,  On- 
Demand  and  Dynamic  Feedback  schemes.  These  schemes  range  from  aggregation  decisions  based  on  static 
thresholds  to  our  ultimate  solution  that  incorporates  a  dynamic  online  feedback  control  mechanism  into  our 
protocol.  A  baseline  without  aggregation  is  also  provided  for  comparison.  Details  of  these  implementations 
are  provided  in  this  section. 

4.2.1.  No  Aggregation 

With  no  aggregation  (the  baseline  scheme),  we  simply  employ  the  normal  network  stack  without  modifica¬ 
tion  passing  packets  directly  from  the  network  protocol  to  the  MAC  protocol  and  vice  versa. 
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4.2.2.  Fixed  Scheme 

In  the  fixed  scheme  (FIX),  AIDA  aggregates  a  fixed  number  of  network  units  into  each  AIDA  payload 
(DOA  =  Nfixed).  When  this  fixed  number  of  network  units  has  been  aggregated,  the  AIDA  payload  is  passed 
down  to  the  MAC  layer  for  transmission.  To  ensure  that  network  units  don’t  wait  an  indefinite  amount  of  time 
before  being  sent,  we  also  incorporate  a  timeout  value  (Tflxed)  into  this  scheme  to  ensure  that  aggregation  is 
performed,  regardless  of  the  number  of  network  units,  within  some  time  threshold.  The  design  of  the  FIX 
scheme  is  shown  in  Figure  4. 


Figure  4:  AIDA  FIX  scheme  Figure  5:  AIDA  On-Demand  scheme 


4.2.3.  On-Demand  Scheme 

To  prevent  unnecessary  per  hop  delay,  our  On-Demand  scheme  monitors  the  AIDA  output  queue  to  ensure 
that  there  is  always  an  AIDA  payload  resident  for  MAC  layer  dequeing  and  transmission.  When  the  MAC  is 
available  for  transmission,  no  network  units  will  be  held  back  by  the  AIDA  layer  in  an  attempt  to  achieve  a 
higher  DOA  (unless  the  maximum  MAC  unit  size  is  reached).  AIDA  layer  data  aggregation  only  takes  place 
when  time  is  available  (the  outbound  message  queue  has  built  up  or  the  medium  is  busy  preventing  the  MAC 
layer  from  accessing  the  channel).  This  scheme  provides  virtually  transparent  aggregation  without  incurring 
message  delay  costs.  The  inner  works  of  the  On-Demand  scheme  is  shown  in  Figure  5.  It  is  worth  noting  that 
the  On-Demand  Scheme  is  a  reactive  solution,  where  passive  measures  allow  the  DOA  to  dynamically  change 
with  varying  traffic  patterns.  When  there  is  little  traffic,  the  outbound  message  queue  rarely  builds  up  and  no 
aggregation  is  performed.  As  traffic  increases,  the  length  of  the  outbound  message  queue  increases  resulting 
in  a  proportional  increase  in  the  DOA. 

As  shown  in  Figure  5,  the  On-Demand  scheme  only  requires  simple  monitoring  logic  to  test  whether  the 
outbound  queue  is  empty  or  not.  This  simplicity  of  code  is  preferable  for  a  constrained  sensor  node.  It  should 
be  noted  that  by  aggregating  a  train  of  network  units  with  one  MAC  header  per  aggregate,  ON -Demand 
scheme  can  reduce  the  header  overhead  than  the  scheme  that  plainly  flushes  all  packets  out  in  the  queue. 

4.2.4.  Dynamic  Feedback  Scheme  (DYN) 

Our  ultimate  solution,  the  Dynamic  Feedback  scheme  (DYN),  implements  a  combination  of  on-demand 
and  fixed  aggregation  where  the  DOA  threshold  (NDYn)  is  adjusted  dynamically.  As  shown  in  Figure  6,  the 
scheme  works  by  monitoring  the  AIDA  output  queue  to  determine  its  availability  while  also  collecting  data  on 
the  queuing  delay  imposed  on  AIDA  payloads  awaiting  transmission.  Using  this  information  and  operating 
under  the  basic  premise  of  control  theory,  our  aggregation  mechanism  dynamically  adjusts  the  degree  of  ag¬ 
gregation  (DOA=NDYn)  to  converge  MAC  delay  to  a  certain  set  point.  This  scheme  begins  with  NDYn  set  to 
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one.  In  the  case  of  low  network  traffic,  DYN  will  default  to  the  On-Demand  mechanism  delivering  packets  to 
the  MAC  transmission  queue  as  soon  as  they  are  ready.  As  network  traffic  builds  up  and  the  contention  delays 
transmission,  our  feedback  loop  adjusts  our  admission  threshold  (NDYn)  to  allow  a  greater  degree  of  aggrega¬ 
tion  prior  to  sending. 


Network 
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Output  Queue 

Input 

Queue 
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AIDA 


De -Aggregator 


Input 
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MAC 


DYN 

Aggregator 

^  Dela_DOA 

Controlle 

r 

ClsEmpty')- 

} - Counting  ^  Queuing 

1 -  Delay 
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Figure  6:  AIDA  Dynamic  Feedback  scheme 

Feedback  Control  Design: 

Intuitively,  an  algorithm  based  on  heuristics  rather  than  theoretical  foundations  can  be  used  to  adjust  the 
DOA  values  to  affect  the  MAC  layer  delay  a  packet  experiences.  When  the  MAC  delay  increases,  the  DOA 
threshold  increases  to  lower  the  feeding  rate  to  the  MAC  layer.  As  a  result,  fewer  nodes  participate  in  channel 
contention  leading  to  a  lower  MAC  delay.  However,  since  heuristic  feedback  control  lacks  knowledge  of  sys¬ 
tem  dynamics,  it  is  subject  to  over  or  under  reaction  and  cannot  adapt  to  the  system  well.  This  warrants  the 
development  of  an  analytical  model  to  reveal  the  dynamics  between  DOA  values  and  the  MAC  layer.  Such  a 
model  serves  as  a  guide  for  developing  an  appropriate  feedback  controller. 

It  is  common  practice  to  use  a  time  slotted  approach  (e.g.  in  AFHOA  and  CSMA)  to  analyze  the  perform¬ 
ance  of  contention-based  protocols  and  establish  a  system  model.  Here  while  our  approach  does  not  assume  a 
slotted  MAC,  we  adopt  this  analysis  technique  to  simplify  problem  formulation.  The  modeling  process  goes  as 
following: 

A  general  form  for  calculating  MAC  delay  can  be  defined  as 


D  (k)  =  D  ■  +#collisions{k)*  D  , 

mac V  /  minimum  ^  res  love 


(l) 


where  Dmac(k)  is  the  MAC  delay  packets  experience  during  time  period  [k,k+l],  Dminimum  is  the  MAC  delay 
when  no  collision  is  experienced,  and  it  is  the  performance  set  point  that  control  loop  wants  to  achieve. 
#collisions(k)  is  the  number  of  collisions  a  successful  transmission  will  encounter  at  time  interval  \k,k+  /], 
and  Dresiove  is  the  collision  delay  plus  the  time  to  resolve  a  single  collision,  also  considered  to  be  a  constant. 
It  should  be  noted  that  (1)  establishes  the  model  for  the  MAC  layer.  The  wait  delay  to  build  an  AIDA 
packet  is  traffic -dependent  and  should  not  be  considered  in  MAC  modeling  process. 

Assume  at  a  certain  time  interval  N(k)  packets  from  different  sensor  nodes  are  ready  for  transmission.  Sta¬ 
tistically,  AIDA  will  pass  down  only  an  average  of  N(k)/DOA(k)  packets  to  actively  compete  for  the  channel. 
DOA(k)  here  is  the  average  DOA  values  of  the  all  nodes  who  compete  for  the  channel.  We  denote  the  prob¬ 
ability  of  a  packet  being  transmitted  at  this  time  period  by  the  symbol  x.  This  x  value  is  a  function  of  the  type 
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of  MAC  protocol.  An  outgoing  packet  encounters  a  collision  when  it  overlaps  with  the  transmission  of  at  least 
one  other  packet  from  the  remaining  N(k)/DOA(k)-l  packets.  Accordingly,  the  average  collision  probability  P 
can  be  calculated  as 


p  =  l-(l-T) 


N(k)l  DOA(k)- 1 


N!DOA>\ 


Naturally,  the  average  number  of  transmissions  required  for  each  successful  transmission  is 

1  (3) 

E(#collsions  +  1)  = - 

(1  ~P) 

Substituting  (2)  into  (3)  gives  us  the  expected  number  of  collisions  each  successful  transmission  will  en¬ 
counter. 

1  (4) 

E(#collsions)  = -  .  .  -1  N I  DOA>\ 

v  '  Q_^N(k)/DOA(k)- 1 


Combining  (1)  and  (4)  then  gives  us  the  approximate  correlation  between  the  DOA  values  and  the  MAC  layer 
delay 

!  *(*)  (5) 

D  (k)=  Id..  -D  ,  ]+D  .  (1-r)  D0A(k) 

mac  k  /  L  minimum  reslove  J  reslove  k  / 


Since  Dminium,  Dresiove  and  x  are  independent  of  DOA  values,  we  calculate  the  differential  of  equation  (5) 
and  get  the  small-signal  model  for  the  system: 

A  ,  _ 1 _  (6) 

D  (k  + 1)  =  D  (. k )  + - -  A,  DOA(k >  A DOA(k) 

DOA(k f  " 

DOA(k  + 1)  =  DOA(k)  +  A  DOA(k) 
where  Ax  =  Dreslove  *  (1  -  T)N(k)(Ln(  1-  T),  A2=(l-  T)~m) 


Because  Al  and  A2  are  independent  of  the  DOA,  they  can  be  considered  constant  in  the  vicinity  of  a 
small  signal  control  model.  Note  that  the  goal  of  this  approximate  model  (6)  is  not  used  to  precisely  calculate 
MAC  delay  under  different  DOA  settings,  but  is  used  to  design  our  controller.  A  tailored  model  can  be  estab¬ 
lished  by  deriving  on  the  values  of  Al  and  A2  based  on  particular  properties  of  the  chosen  MAC  protocol. 
However,  for  the  sake  of  MAC-independence,  we  design  a  general  form  for  our  controller  in  accordance  with 
equation  (6)  as  follows. 

A DOA(k)  =  G(k)*e(k)  (7) 

where  G{k)  =  PDOA  * DOA(k)2  e(k)  =  (Dmac (k)  -  Dmmwmm ) 

In  equation  (7),  PDoa  is  an  implementation  parameter  to  set  the  gain  between  the  changes  of  DOA  and  the 
error  in  MAC  delay  control.  Thus  AIDA  is  essentially  modeled  as  a  first-order  system  and  therefore  the  gain 
G(k)  in  equation  (7)  does  not  need  to  be  constant  for  stability  analysis,  as  long  as  G(k)  is  bounded.  The  picto¬ 
rial  notation  of  this  control  loop  is  shown  in  Figure  7. 


Figure  7 :  The  control  loop  for  the  DYN  AIDA  scheme 
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As  we  will  show  in  the  evaluation,  the  current  adaptive  controller  works  best  under  a  wide  range  of  traffic 
scenarios  under  investigation.  However,  we  acknowledge  that  the  modeling  portion  of  our  work  has  room  for 
improvement  to  precisely  reflect  the  nonlinear  behavior  of  the  MAC  contention. 

4.3.  AIDA  Function  Unit 

The  AIDA  Aggregation  Function  Unit  (Figure  2)  is  responsible  for  the  aggregation  and  de-aggregations  of 
network  units.  This  component  builds  four  different  types  of  aggregates,  namely  Unicast,  Manycast,  Multicast 
and  Broadcast,  in  accordance  with  the  set  AIDA  parameters  and  current  state  of  the  module. 

•  If  there  is  only  one  network  unit  ready  when  the  AIDA  Control  Unit  is  ready  to  aggregate  (e.g.  a 
time  out  occurs),  the  AIDA  Function  Unit  will  use  Unicast  to  send  the  waiting  unit  out  to  the 
specified  neighboring  node.  In  this  case,  no  aggregation  is  performed. 

•  If  all  network  units  to  be  aggregated  are  targeting  the  same  next-hop  node,  AIDA  sends  out  an  ag¬ 
gregate  using  Manycast  with  the  target  specified. 

•  When  network  units  to  be  aggregated  have  different  next-hop  addresses,  the  slightly  more  com¬ 
plex  Multicast  type  is  used  to  take  advantage  of  the  broadcast  nature  of  wireless  communication. 
In  this  case,  AIDA  merges  network  units,  regardless  of  which  neighbor  each  network  unit  targets, 
into  a  single  aggregate  and  uses  the  MAC  broadcast  address  as  the  destination.  Every  neighbor  of 
the  sending  node  will  receive  and  de-aggregate  this  Multicast  packet  to  determine  whether  or  not  a 
portion  of  the  aggregated  payload  was  destined  to  it. 

•  Finally,  the  Broadcast  type  of  AIDA  is  used  in  the  case  where  ah  aggregated  network  units  are 
Broadcast  messages. 

Although  a  single  packet  format  (Multicast)  is  logically  enough  to  support  all  of  the  aforementioned  sce¬ 
narios,  we  argue  that  tailored  packet  formats  for  each  scenario  can  reduce  the  AIDA  header  size  and  save 
bandwidth.  These  savings  are  beneficial  in  a  resource  constrained  sensor  network  justifying  the  small  amount 
of  complexity  added  through  AIDA  typing. 

4.4.  Packet  Format  Details 

Fike  most  communication  stack  layers,  AIDA  adds  meta-information  to  a  packet  in  the  form  of  a  header. 
This  header  defines  the  aggregation  format  used  for  later  de-aggregation,  de-multiplexing,  and  seamless  deliv¬ 
ery  to  the  appropriate  network  layer  protocol.  This  header  is  placed  in  front  of  all  aggregated  network  units 
and  is  included  in  the  AIDA  data  units  passed  down  to  the  MAC  layer  for  transmission.  Upon  delivery  at  a 
node,  the  AIDA  header  can  then  be  used  to  validate  the  specific  aggregation  mechanism  used  (in  the  case 
where  multiple  aggregation  options  are  provided),  assess  the  structure  of  the  AIDA  payload  for  de-aggregation, 
and  potentially  break  apart,  de-multiplex,  and  deliver  each  network  unit  to  the  appropriate  network  layer  mod¬ 
ule. 

It  should  be  noted  that  by  aggregating  the  network  payloads,  AIDA  reduces  the  number  of  packets  sent  at 
the  MAC  layer,  thus  actually  reduce  overall  header  cost.  The  general  form  of  the  AIDA  header  is  provided  in 
Figure  8.  Some  fields  inside  this  general  form  are  not  used  for  certain  AIDA  payload  types. 

_ _ _ Variable  size _ _ _ 

MAC  I  AIDA  I  UNIT1  (IP  etc)  |  UNIT2  |  UNIT3  | 
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Figure  8 :  AIDA  General  Header  format 
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4.4.1.  FLAG  for  All  Types 

The  first  component  of  the  AIDA  header  is  an  eight  bit  ( 1  byte)  flag  specifying  information  relevant  to  all 
aggregated  network  units.  The  Flag  is  composed  of  a  Type  field  (2  bits),  a  protocol  field  (2  bits),  and  the 
number  of  Next  Headers  (4  bits). 

•  Type  Field:  The  Type  bits  are  used  to  specify  whether  the  AIDA  packet  should  be  treated  as  a  Uni¬ 
cast,  Manycast,  Multicast ,  or  Broadcast. 

•  Protocol  Field:  The  Protocol  field  (2  bits)  of  the  AIDA  Flag  denotes  to  which  network  layer  AIDA 
should  de-multiplex  network  units. 

•  Num  Receiver/Units:  This  filed  (4  bits)  denotes  how  many  headers  follow.  For  Unicast,  Manycast 
and  Broadcast  traffic,  this  field  is  set  to  the  number  of  network  units  inside  this  aggregate.  For  Multi¬ 
cast  traffic  this  field  will  contain  the  number  of  neighbors  receiving  portions  of  this  aggregate. 

4.4.2.  Receiver  Field  for  Multicast  Type 

The  Receiver  Field  is  only  used  by  Multicast  AIDA  packets.  Each  field  contains  an  ID  specifying  the  in¬ 
tended  recipient  followed  by  the  number  of  network  units  contained  in  this  aggregate  that  are  destined  for  the 
specified  neighbor.  In  the  case  of  Unicast,  Manycast  or  Broadcast  AIDA  payloads,  there  is  no  need  to  differ¬ 
entiate  between  receiving  nodes  so  this  field  is  not  used. 

•  ID  Filed:  The  ID  field  (2  bytes)  contains  a  locally  unique  identifier  of  the  node  receiving  a  specified 
number  of  network  units. 

•  Num  Units  For  this  ID  Field:  This  field  is  an  8  bit  (1  byte)  field  that  identifies  the  number  of  aggre¬ 
gate  network  units  that  are  destined  for  the  neighbor  specified  in  the  ID  Field. 

4.4.3.  Unit  Field 

UNIT  filed  is  used  during  de-aggregation  for  delimiting  the  boundaries  between  network  units.  It  consists 
of  a  16  bit  (2  byte)  field  that  specifies  the  size  of  each  network  units.  In  the  Unicast  case  there  is  no  boundary 
to  be  identified,  so  the  UNIT  field  is  not  used. 

4.5.  AIDA  Header  Overhead  Analysis 

First,  it  should  be  reminded  that  though  AIDA  introduces  a  new  header,  it  actually  reduces  overall  header 
overhead  by  aggregating  several  network  units  into  one  MAC  payload;  For  example,  in  802.11  the  MAC 
header  length  is  28  bytes.  To  send  out  N  network  units  without  AIDA,  the  total  header  overhead  would  be 
28*N  bytes.  Using  AIDA  we  reduce  the  total  header  overhead  to  28+AIDAHeaderSize  bytes.  As  long  as  the 
value  of  N  (the  DOA)  is  greater  than  1,  AIDA  effectively  reduces  the  total  packet  overhead  incurred  during 
transmission. 

It  is  simple  to  assess  the  overhead  incurred  during  the  aggregation  of  network  units  according  to  the  de¬ 
scription  in  section  4.4.  For  comparison,  the  packet  structure  with  and  without  AIDA  is  shown  in  Figure  9. 

_ _ _ Variable  size _ _ _ 

MAC  |  AIDA  |  UNIT1  (IP  etc)  |  UNIT2  |  UNIT3  | 


AIDA  aggregate 


MAC 

UNITl(IPetc) 

MAC 

UNITl(IPetc) 

Normal  Packets 


Figure  9:  Format  Comparison 

■  Unicast  only  uses  the  Flag  field  and  therefore  incurs  a  single  byte  of  overhead. 

■  Besides  the  1  byte  flag,  Manycast  and  Broadcast  packets  need  to  delimitate  the  boundaries  of  multiple 
network  units,  thus  incurring  an  average  of  (2+1/N)  bytes  overhead  per  network  unit  (where  N  is  the 
number  of  network  units  aggregated  into  an  AIDA  payload  ). 
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■  Because  multiple  next-hop  node  addresses  need  to  be  differentiated,  Multicast  payloads  have  a  slightly 
larger  overhead  on  the  average  (2+1/N+3/M)  bytes  per  network  unit  (where  N  is  the  same  as  before 
and  M  is  the  average  number  of  network  units  for  each  next-hop  node), 

4.6.  AIDA  Savings  Analysis 


Adding  header  information  to  any  transmission  will  intuitively  increase  transmission  time  for  a  single 
packet.  We  therefore  only  see  savings  in  per  transmission  overhead  costs  when  aggregating  multiple  upper 
layer  payloads  into  a  single  transmission.  By  analyzing  our  AIDA  header  structure,  we  can  see  that  savings 
differ  for  Unicast,  Manycast,  and  Multicast  transmissions.  To  better  understand  the  potential  benefits  of  aggre¬ 
gation,  and  to  compare  different  levels  of  aggregation  under  different  traffic  patterns,  we  provide  a  theoretical 
analysis  to  assess  overhead  with  respect  to  transmission  time.  The  analysis  presented  assumes  optimal  aggre¬ 
gation  to  the  specified  DOA  without  incurring  any  additional  cost  waiting  for  network  layer  payloads.  We 
also  assess  savings  without  considering  collisions  and  backoff,  two  factors  that  will  ultimately  increase  the 
utility  of  AIDA. 

The  cost  of  packet  transmission  in  the  simple  single  sender,  single  receiver  scenario  with  no  channel  con¬ 
tention  and  an  arbitrary  MAC  layer  is  the  time  consumed  by  the  MAC  acquiring  and  setting  up  each  transmis¬ 
sion  plus  the  time  for  sending  the  message,  ah  multiplied  by  the  number  of  individual  transmissions.  To 
maintain  MAC  layer  independence,  we  simply  assign  the  variable  M,  to  the  time  (in  msec)  for  performing 
MAC  layer  transmission  preparation.  For  an  802.11  like  MAC,  this  cost  includes  the  channel  sense,  RTS, 
CTS,  ACK,  and  intermittent  wait  times  between  control  packets.  For  network  units  of  size  S  transmitted  at  R 
bytes/second,  the  AIDA  header  overhead  is  O  (in  bytes),  and  DOA  is  the  number  of  packets  aggregated.  The 
cost  Caida  (in  msec)  can  be  calculated  from  equation  (8): 

CAIDA=M +  (S*D0A  +  0)*R  (8) 

In  contrast,  the  cost  of  sending  DOA  number  of  packets  without  the  aggregation  scheme  CNone  is 

CNone=(M  +  S*R)*DOA  (9) 


Hence,  the  percentage  saving  in  cost  is  calculated  as  following: 

SavingPercentage  =  CNone  ~  C A1DA  )  =  1 - — - - 

Ca*.  L 


M  +0* R  .  1 

_ * _ 

M+S*R  DOA 


(10) 


From  equation  10,  we  can  see  that  the  saving  increases  as  the  DOA  increases  when  the  cost  at  the  MAC 
layer  (M)  is  non-negligible.  To  demonstrate  the  utility  of  AIDA,  we  graph  theoretical  savings  for  our  scheme 
under  an  802.1 1  like  MAC  contention  scheme  for  a  200  Kbps  channel.  The  AIDA  payload  is  passed  down  to 
a  simplified  802.11  MAC  that  performs  idle  listening,  RTS/CTS  handshaking,  and  follows  up  each  DATA 
packet  with  an  acknowledgment.  The  control  packet  size  for  our  theoretical  MAC  is  1 1  bytes.  Contention 
also  includes  5  msec’s  of  idle  listening  and  the  DIFS  and  SIFS  intervals  are  chosen  at  10  and  5  msec’s  respec¬ 
tively  in  accordance  with  the  current  MICA  specifications.  We  graph  variable  size  network  units  to  better  un¬ 
derstand  the  effect  of  packet  size  on  potential  savings. 

Figure  10  demonstrates  theoretical  time  savings  as  a  percentage  of  the  total  time  it  would  take  to  send  the 
number  of  packets  without  AIDA.  These  savings  are  calculated  by  comparing  the  time  to  send  a  single  AIDA 
aggregate,  consisting  of  [DOA]  network  units  with  one  MAC  header,  versus  the  time  to  send  [DOA]  separate 
packets  without  any  AIDA  header  information  or  data  aggregation  performed.  From  this  chart  we  can  see  that 
as  the  degree  of  aggregation  increases,  the  percentage  of  savings  in  time  increases  drastically.  We  also  note 
that  as  payload  size  increases,  the  relative  time  saving  decreases.  This  occurs  when  data  transmission  time 
becomes  a  larger  percentage  of  the  total  transmission  time.  Finally,  we  note  that  when  AIDA  fails  to  perform 
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any  aggregation  as  shown  in  Figure  10  when  DO  A  =  1,  the  cost  incurred  is  a  single  byte  of  data,  which 
amounts  to  virtually  no  increase  in  transmission  time. 


Degree  of  Aggregation  (DOA) 


□  60  byte  payloads 
■  120  byte  payloads 

□  180  byte  payloads 

□  240  byte  payloads 


Figure  10:  AIDA  Theoretical  Savings 


5.  Evaluation 

We  simulate  AIDA  in  GloMoSim,  a  scalable  discrete-event  simulator  developed  at  UCFA.  This  software 
provides  a  high  fidelity  simulation  for  wireless  communication  with  detailed  propagation,  radio,  MAC,  and 
network  layer  components.  Table  1  describes  the  detailed  setup  for  our  simulator.  For  our  experiments  the 
communication  parameters  are  mostly  chosen  in  accordance  with  Berkeley  MICA  mote  specifications  [34],  the 
popular  hardware  platform  on  which  sensor  network  research  systems  are  currently  deployed  for  testing.  The 
current  version  of  the  MICA  motes  supports  a  40kbps  transmission  rate  and  the  next  generation  is  expected  to 
provide  higher  than  1Mbps  rates.  Based  on  these  considerations,  we  choose  40  ~  200Kb/s  as  the  effective 
bandwidth  for  our  evaluation  (default  200Kbps  unless  otherwise  specified).  Finally,  we  choose  802.11  as  our 
MAC  layer  protocol,  which  has  been  implemented  in  a  scaled  down  version  on  the  MICA  platform. 


Routing 

GF 

MAC  Fayer 

Simplified  802.11  DCF 

Radio  Fayer 

RADIO-ACCNOISE 

Propagation  model 

TWO-RAY 

Bandwidth 

40  ~  200Kb/s 

Payload  size 

32  Byte 

TERRAIN 

(200m,  200m) 

Number  of  Motes 

100 

Node  placement 

Uniform 

Radio  Range 

40m 

Table  1.  Simulation  settings 


Since  our  work  is  the  first  we  know  of  concerning  data  aggregation  without  utilizing  application  informa¬ 
tion,  we  evaluate  our  work  based  on  different  aggregation  schemes  we  provide  and  a  normal  stack  without  ag¬ 
gregation  support.  In  this  evaluation  we  compare  the  performance  of  four  schemes:  No-aggregation,  FIX,  On- 
Demand,  and  DYN  as  previously  defined.  We  show  that  DYN  feedback  is  the  best  solution  with  better  per¬ 
formance  under  all  traffic  scenarios  tested. 

In  our  evaluation,  we  analyze  the  following  set  of  metrics:  end-to-end  delay,  energy  consumption,  MAC 
control  packets,  degree  of  aggregation  (DOA)  and  AIDA  control  overhead.  These  metrics  are  investigated  un¬ 
der  three  sets  of  typical  traffic  patterns  with  a  total  of  72  different  traffic  loads,  which  allow  us  to  access 
AIDA’s  adaptation  capability  under  a  wide  range  of  traffic  situations.  Each  plotted  data  point  is  the  average  of 
10  runs  generated  from  different  random  seed  values.  This  ensured  that  95%  confidence  intervals  for  our  data 
are  within  2~5%  of  obtained  means.  For  legibility  reasons  we  do  not  plot  these  confidence  intervals  in  this 
paper.  Full  experimental  data  can  be  obtained  from  the  authors  upon  request. 
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5.1.  Work  load  Settings 

We  expect  typical  communication  patterns  inside  a  sensor  network  to  be  established  based  on  request  and 
retrieval  semantics  for  data  delivery  between  sensor  nodes  and  a  querying  entity.  One-to-one,  many-to-one  and 
many-to-many  communication  patterns  are  representative  workloads  in  sensor  networks.  One-to-one  commu¬ 
nication  happens  when  one  sentry  node  detects  some  activity  that  needs  to  be  reported  to  a  remote  entity.  Al¬ 
ternatively,  a  quering  entity  will  require  periodic  reports  from  the  whole  sensor  area,  which  take  the  form  of 
many-to-one  communication.  It  is  more  common  that  multiple  applications  run  simultaneously  and  the  traffic 
flows  interleave  with  each  other,  which  is  a  many-to-many  cross-traffic  pattern. 


ONE-TO-ONE  MANY-  TO-  ONE  MANY-  TO-  MANY 


24  workloads  per  pattern.  ( random  placement  10  runs) 

Figure  1 1 :  Traffic  Load  Settings 

In  our  evaluation  we  focus  on  the  aforementioned  three  representative  communication  patterns  (Figure  1 1). 
To  test  the  one-to-one  scenario,  we  have  a  single  node  randomly  placed  on  the  left  lower  corner  of  our  terrain 
send  out  a  single  CBR  flow  to  the  right  upper  corner  of  the  terrain  where  the  average  route  is  approximately 
6~7  hops.  In  the  many-to-one  scenario,  10  nodes  on  the  left  side  of  the  terrain  send  out  10  CBR  flows  to  the 
center-right  side  of  the  terrain  where  we  place  a  single  querying  node.  In  many-to-many  scenario,  5  nodes  on 
the  left  side  of  the  terrain  send  out  10  CBR  flows  (2  flows  for  each  node)  to  the  two  querying  nodes  at  the  up¬ 
per  and  lower  right  corner  of  the  terrain,  respectively.  The  sending  rate  of  each  CBR  flow  is  incrementally  in¬ 
creased  to  test  the  performance  of  AIDA  under  different  traffic  loads. 

5.2.  End-To-End  Delay 

5.2.1.  End-to-end  delay  under  different  schemes 

A  major  goal  of  the  AIDA  protocol  is  to  achieve  energy  savings  without  jeopardizing  end-to-end  delay. 
AIDA  not  only  doesn’t  add  to  the  end-to-end  delay,  but  in  the  presence  of  high  degrees  of  aggregation, 
actually  decreases  end-to-end  delay  by  reducing  the  number  of  control  packets  used  at  the  MAC  layer. 

Figure  12,  Figure  13  and  Figure  14  graph  end-to-end  delay  as  a  function  of  traffic  loads  under  three  traffic 
scenarios.  These  graphs  show  that  end-to-end  delay  for  CBR  without  performing  aggregation  increases  dra¬ 
matically  as  the  overall  traffic  increases  gradually.  This  is  the  typical  case  for  multi-hop  wireless  networks 
where  channel  contention  is  much  higher  than  in  a  single  hop  wireless  LAN,  As  shown  in  figures,  when  traffic 
is  low  (e.g.  below  3  packets/per  flow  in  Figure  13  ),  all  schemes  except  the  FIX  have  very  short  end-to-end 
delay  (abut  70~  100ms).  The  reason  for  additional  delay  in  the  FIX  scheme  is  because  the  FIX  scheme  holds 
packets  despite  an  available  channel  in  order  to  obtain  its  specified  degree  of  aggregation.  The  lower  the  send¬ 
ing  rate  is,  the  longer  the  FIX  scheme  needs  to  wait.  In  contrast,  the  On-Demand  and  DYN  schemes  send  out 
packets  whenever  possible,  eliminating  any  additional  end-to-end  delay.  On-Demand  scheme  performs  well 
because  of  its  reactive  adaptive  mechanism.  The  DYN  scheme  performs  the  best  in  all  scenarios  because  it 
dynamically  adjusts  the  required  DOA  according  to  the  MAC  delay  that  the  outgoing  packets  experience.  In 
heavy  traffic,  it  is  beneficial  to  reduce  number  of  node  competing  for  the  channel  by  reducing  sending  rate.  In 
the  presence  of  extremely  heavy  traffic,  we  show  that  DYN  scheme  is  capable  of  reducing  the  end-to-end  de¬ 
lay  by  as  much  as  80%,  compared  to  non-aggregation  case,  when  flow  rate  at  8.5  packets/second  per  flow  (see 
Figure  14 ). 
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♦  1  None 

8000  - 

♦  -  None 

■  FIX 

^  7000  - 

■  FIX 

—A — ONDEMAND 

^  6000  - 

—A — ONDEMAND 

X  DYN 

ca 

q  5000  - 

— X — DYN 

26  32  38  44  50 

Traffic  (  #packet/second  per  CBR  flow) 


1.8  3  4.2  5.4  6.6 

Traffic  (  #packet/second  per  CBR  flow) 


Figure  12:  Avg  E2E  delay  (one-to-one  200Kbps)  Figure  13:  Avg  E2E  delay  (many-to-one  200  Kbps) 


Figure  14:  Avg  E2E  delay  (many-to-many  200Kps) 


5.2.2.  End-to-end  delay  under  different  available  bandwidth  settings 

In  this  experiment,  we  investigate  the  end-to-end  delay  under  the  different  bandwidth  settings.  The  work¬ 
loads  are  chosen  differently  for  each  bandwidth  setting  in  order  to  compare  the  performance  of  each  scheme 
under  from  underutilized  to  saturated  traffic  situations. 


Figure  15:  E2E  delay  (one-to-one  under  40Kps)  Figure  16:  E2E  delay  (one-to-one  under  lOOKps) 

The  Figure  12,  Figure  15  and  Figure  16  demonstrate  that  DYN  scheme  out  performances  other  schemes 
regardless  the  available  bandwidth  settings.  This  is  mainly  because  that  DYN  can  more  effectively  aggregate 
and  schedule  the  packets  according  to  the  feedback  of  the  currently  traffic  situations  than  other  schemes.  Base 
on  such  an  investigation,  we  conclude  that  the  improvement  made  by  DYN  scheme  over  other  schemes  is  or¬ 
thogonal  to  the  available  bandwidth  setting,  though  the  absolute  performance  gain  may  vary. 
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5.2.3.  End-to-end  delay  under  different  DOA  setting  for  the  FIX  scheme 

In  this  experiment,  we  measure  end-to-end  delay  for  various  traffic  loads  under  different  DOA  settings  in 
the  FIX  scheme.  Figure  17  reveals  the  disadvantage  of  the  FIX  scheme  and  explains  why  dynamic  adaptability 
is  desired  for  such  system.  From  Figure  17,  we  can  see  that  there  is  no  single  DOA  value  that  works  well  for 
every  traffic  pattern. 
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< 

1000 
0 

0.004  0.006  0.008  0.01  0.012 

Energy  Per  Packet  Delivered  (mWh) 

Figure  17:  Avg  E2E  delay  (many-to-one)  Figure  18  E2E  Delay  vs.  Energy  (many  to  one) 

On  one  hand,  a  high  DOA  value  in  the  FIX  scheme  doesn’t  perform  well  under  low  traffic  loads.  For  ex¬ 
ample,  when  the  DOA  is  higher  than  1 ,  additional  delay  is  incurred  when  the  traffic  load  is  0.5  packets/second 
per  flow  or  lower.  The  higher  DOA  settings  tend  to  reduce  congestion,  but  increase  delay  in  the  AIDA  compo¬ 
nent  for  packets  waiting  to  be  sent.  On  the  other  hand,  low  DOA  value  settings  don’t  perform  well  under 
heavy  traffic.  For  example,  shown  in  Figure  17,  the  FIX  scheme  with  DOA  =  1  has  nearly  double  the  end-to- 
end  delay  as  that  with  DOA=2  when  the  traffic  is  about  10  packet/second  per  flow  or  higher. 

In  addition,  Figure  18  demonstrates  the  performance  penalty  due  to  the  lack  of  adaptability  in  the  FIX 
scheme.  We  plot  the  relationship  between  average  end-to-end  delay  and  average  energy  consumption  per 
packet  delivered  under  different  CBR  rates  form  one  to  six  packets/second.  Under  the  light  traffic  (e.g.  one 
packets/per  second  per  CBR),  the  FIX  scheme  needs  to  hold  back  packets  in  order  to  reduce  energy  consump¬ 
tion.  Under  heavy  traffic,  (e.g.  six  packets/per  second  per  CBR),  the  FIX  scheme  would  cause  an  increase  in 
both  delay  and  energy  consumption  by  choosing  a  fixed  DOA  value  that  doesn’t  reflect  the  traffic  load. 

The  FIX  scheme  is  insensitive  to  the  traffic  situations.  To  optimize  for  both  light  and  heavy  traffic,  online 
adaptation  is  provided  in  On-Demand  and  DYN  schemes,  which  can  passively  and  proactively  change  the 
DOA  value  in  accordance  with  these  traffic  patterns,  respectively.  Therefore,  they  exhibit  a  better  overall  per¬ 
formance  as  shown  in  Figure  12,  Figure  13  and  Figure  14. 

5.3.  Energy  Consumption 

In  this  section,  Energy  consumption,  in  transmission  energy,  is  adopted  as  another  revealing  metric  to 
evaluate  the  AIDA  performance.  Since  transmission  energy  increases  proportionally  with  the  number  of  bits 
sent  out,  it  can  adequately  summarize  and  reflect  the  performance  of  other  related  metrics  such  as  total  header 
overhead,  number  of  collision,  total  number  of  bit  transmitted  bytes. 

5.3.1.  Energy  consumption  under  different  schemes 

With  limited  power  resources,  it  is  vital  for  sensor  nodes  to  minimize  energy  consumption  during  radio 
communication  to  extend  the  lifetime  of  the  sensor  network.  AIDA  achieves  such  energy  savings  via  several 
approaches.  First,  AIDA  reduces  MAC  channel  contention  costs  by  distributing  these  costs  across  multiple 
network  units.  Second,  by  using  less  MAC  control  packets,  AIDA  dampens  congestion  and  reduces  the  num¬ 
ber  of  collisions  resulting  in  fewer  retransmissions.  Finally,  networking  protocols  designed  for  sensor  net¬ 
works  usually  adopt  fixed  packet  sizes  (e.g.  TinyOS  networking  [14]),  which  leads  to  unnecessary  padding 
costs.  In  our  simulation  with  variable  size  support,  AIDA  takes  advantage  of  the  first  two  approaches. 
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Figure  19:  Energy  per  unit  delivered  (  one-to-one  ).  Figure  20:  Energy  per  unit  delivered  (many-to-one) 
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Figure  21:  Energy  per  unit  delivered  (many-to-many)  Figure  22:  Energy  per  unit  delivered  (FIX  scheme) 
In  this  experiment,  we  measure  average  transmission  energy  per  delivered  packet  under  24  increasing  traf¬ 
fic  loads  for  three  traffic  patterns.  In,  Figure  19,  Figure  20  and  Figure  21,  our  energy  metrics  show  that  the 
scheme  without  AIDA  (None)  demonstrates  the  worst  performance.  For  example,  None  consumes  double  the 
energy  as  the  DYN  scheme  when  traffic  load  is  about  6  packets/second  per  flow  in  Figure  2 1 .  The  FIX  scheme 
always  aggregates  2  packets  before  sending  which  leads  to  nearly  constant  energy  saving  in  both  the  low  and 
high  traffic  situation.  However,  in  the  FIX  scheme,  the  DOA  values  are  set  and  congestion  levels  are  not  taken 
into  account  resulting  in  worse  performance  than  in  DYN  and  On-Demand  schemes  under  heavy  traffic  condi¬ 
tions.  For  example,  shown  in  Figure  21,  in  DYN  scheme,  nodes  consumes  about  20%  less  energy  per  packet 
delivered  as  in  the  FIX  scheme,  when  traffic  load  is  about  8  packets/second  per  flow. 


5.3.2.  Energy  consumption  under  different  DOA  for  the  FIX  scheme 

Figure  22  shows  energy  consumption  per  packet  delivered  for  varying  DOA’s  under  the  FIX  scheme.  This 
graph  shows  that  for  the  FIX  scheme,  AIDA  can  achieve  a  higher  percentage  of  energy  savings  by  using 
higher  DOA  values.  However,  as  we  have  shown  in  section  5.2,  a  higher  DOA  leads  to  additional  delay  when 
the  network  is  lightly  loaded,  therefore  taking  end-to-end  delay  into  account,  it  is  not  always  beneficial  to  in¬ 
crease  the  DOA  value. 


5.4.  MAC  control  packets 

Even  though  our  AIDA  design  is  independent  of  any  MAC  layer  protocol,  it  can  reduce  MAC  overhead  by 
sending  longer,  but  less  numerous  payloads  to  the  MAC  layer  for  transmission.  This  reduces  the  number  of 
channel  access  operations  performed  by  the  MAC.  This  section  identifies  the  savings  incurred  through  AIDA 
aggregation  at  the  MAC  layer.  The  data  collected  here  are  for  the  802.1 1  MAC  protocol  although  we  would 
expect  very  similar  results  from  other  MAC  protocols. 

Figure  23,  Figure  24  and  Figure  25  graph  the  number  of  control  packets  sent  over  various  traffic  loads.  As 
shown  in  these  graphs,  the  FIX  scheme  reduces  the  number  of  MAC  control  packets  by  approximately  50% 
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when  the  DOA  parameter  is  set  to  2.  On-Demand  and  DYN  vary  their  DOA  and  therefore  incrementally  re¬ 
duce  MAC  overhead  as  network  congestion  levels  increase.  For  example  shown  in  Figure  25,  when  per  flow 
rate  exceeds  9  packets/second,  DYN  only  used  about  20%  of  the  control  packets  compared  to  the  none- 
aggregation  case.  This  dramatically  reduces  congestion  and  energy  consumption  as  shown  in  other  evaluations. 


Figure  23:  MAC  control  Packets  (one-to-one  )  Figure  24:  MAC  control  Packets  (many-to-one) 


Figure  25:  MAC  control  Packets  (many-to-many) 


5.5.  Degree  of  Aggregation 

As  seen  in  the  context  of  reducing  the  MAC  overhead,  the  degree  of  aggregation  is  a  major  indicator  re¬ 
flecting  AIDA’s  ability  to  achieve  energy  savings  and  congestion  dampening.  Without  aggregation,  the  DOA 
always  equals  one  (e.g.  None  case  in  Figure  26  ).  In  the  FIX  scheme  where  DOA  is  set  to  2,  we  can  see  that  a 
constant  value  for  the  degree  of  aggregation  is  achieved.  In  the  On-Demand  scheme,  the  DOA  naturally  fol¬ 
lows  traffic  congestion  levels.  In  DYN,  the  DOA  is  controlled  by  a  feedback  loop  embedded  inside  AIDA. 


Figure  26:  DOA  (one-to-one  ) 


Figure  27 :  DOA  (many-to-one) 
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Figure  28:  DOA  (many-to-many) 

Figure  26  ,  Figure  27  and  Figure  28  graph  the  achieved  DOA  under  various  traffic  conditions  for  the  tested 
schemes.  Figure  26  shows  how  DYN  has  roughly  the  same  DOA  value  as  the  On-Demand  scheme  in  the  one- 
to-one  pattern  situation.  However,  in  the  more  congested  situations  (Figure  27  and  Figure  28  ),  DYN  achieves 
a  higher  DOA  value  than  On-Demand  resulting  in  more  savings  on  channel  bandwidth  and  energy  consump¬ 
tion. 


5.6.  AIDA  overhead 


As  shown  in  AIDA  Header  Overhead  Analysis  (section  4.5),  AIDA’s  header  overhead  is  about  3  bytes  for 
Multicast  packets,  2  bytes  for  Manycast,  and  1  byte  for  Unicast  and  Broadcast  per  network  unit.  Figure  29, 
Figure  30  and  Figure  31  graph  per  packet  AIDA  overhead  under  various  traffic  loads.  As  shown  in  Figure  30, 
under  many-to-one  conditions,  the  FIX  scheme  will  send  out  only  Manycast  packets  with  its  DOA  value  set  to 
2.  This  leads  to  an  average  of  2  bytes  of  AIDA  header  overhead.  When  the  flow  rate  is  very  low  (shown  by 
the  first  two  values  for  the  FIX  scheme  in  Figure  30),  the  FIX  scheme  times  out  before  it  can  reach  its  aggrega¬ 
tion  level  of  2.  When  this  happens  the  FIX  scheme  sends  Unicast  packets  resulting  in  a  smaller  average  AIDA 
overhead  per  network  unit. 

In  one-to-one  and  many-to-one  traffic  patterns,  AIDA  uses  Unicast  when  the  network  is  not  congested  in 
order  to  avoid  additional  delay  and  Manycast  when  congestion  is  apparent.  This  is  shown  in  Figure  29  and 
Figure  30  as  congestion  levels  increase  and  the  overhead  approaches  2  bytes  per  header.  In  one-to-one  and 
many-to-one  traffic  patterns,  no  multicast  packets  are  sent  out,  explaining  why  AIDA  overhead  never  exceeds 
2  bytes  per  network  unit. 

On  the  contrary,  in  many-to-many  situations,  AIDA  takes  advantage  of  the  broadcast  nature  of  wireless 
networks,  uses  multicast  packets  to  address  multiple  next-hop  nodes  in  a  single  aggregation,  which  require  3 
bytes  overhead  for  each  multicast  packet.  This  is  shown  in  Figure  3 1  where  AIDA  overhead  is  somewhere  be¬ 
tween  2  and  3  bytes  for  the  FIX  scheme. 


Figure  29:  AIDA  overhead  (one-to-one) 


2.5  n 


0.6  1.8  3  4.2  5.4  6.6 


Traffic  (  #packet/second  per  CBR  flow) 


Figure  30:  Aida  overhead  (many-to-one) 
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Figure  3 1 :  Aida  overhead  (many-to-many) 


5.7.  Comparisons  and  Summary 

In  summary,  the  FIX  scheme  does  not  take  congestion  into  account  and  is  not  adaptable  to  changing  traffic 
loads.  There  is  no  single  DOA  value  that  works  well  for  every  traffic  pattern.  The  feedback  information  util¬ 
ized  in  the  ON-DEMAND  scheme  is  essential  binary:  either  the  MAC  component  is  busy  or  free.  This  only 
provides  limited  information  to  the  controller.  In  comparison,  DYN  obtains  delay  information  that  directly 
reflects  the  current  traffic  situation  resulting  in  a  better  control  model  and,  therefore,  better  performance. 


6.  Implementation  on  the  Berkeley  Mote  Test  Bed 

We  have  implemented  the  AIDA  protocol  on  the  Berkeley  motes  platform  with  a  code  size  of  3,840  bytes 
(code  is  available  at  [9]).  Three  applications  including  data  placement  [28],  target  tracking  [6],  and  CBR  are 
built  and  tested  on  top  of  AIDA.  Due  to  the  physical  limitation  on  the  motes,  it  is  extremely  difficult  to  per¬ 
form  as  extensive  evaluation  as  we  did  in  the  wireless  simulator.  As  a  result,  we  only  present  partial  results 
here  as  a  study  to  better  understand  the  effect  of  aggregation  in  developing  a  more  complete  adaptive  solution. 
More  detailed  evaluation  on  upgraded  versions  of  motes  is  left  as  future  work. 


□  None 

□  DOA=2 

□  DOA=3 

■  DOA=4 

□  DOA=5 

Figure  32:  Packets  Sent  Under  different  DOA 

In  the  experiment  we  use  25  motes  to  form  a  5  by  5  grid.  To  evaluate  the  aggregation  performance  of 
AIDA  we  send  three  CBR  flows  (5  bytes  payload)  from  node  24  to  node  0  (the  requesting  node).  The  experi¬ 
ment  collects  the  number  of  packets  relayed  by  intermediate  motes  ( 1  —23)  and  compares  this  with  the  results 
obtained  from  a  basic  GF  [20]  protocol  without  AIDA.  In  some  embedded  designs,  fixed  packet  sizes  are  sup¬ 
ported  for  the  sake  of  simplicity  making  padding  costs  large  when  sensor  data  payloads  are  small.  AIDA  takes 
advantage  of  this  and  aggregates  multiple  payloads  into  one  packet  to  minimize  padding  costs.  The  savings 
achieved  by  AIDA  are  shown  in  Figure  32  graphing  the  number  of  packets  sent  at  intermediate  nodes  under 
various  DOA  settings.  We  demonstrate  that  the  transmission  cost  (packets  sent)  is  reduced  as  the  DOA  value 


20 


ACM  Transaction  on  Embedded  Computing  System 


increases.  For  example,  when  the  DOA  value  is  2,  node  1  sends  out  nearly  half  as  many  packets  as  it  did 
without  aggregation.  It  is  worth  noting  that  with  a  fixed  size  packet,  when  the  DOA  reaches  a  certain  value 
AIDA  comes  to  a  point  where  it  cannot  compact  any  more  network  units  into  the  AIDA  aggregate.  For  our 
experiment  and  payload  size  this  occurred  when  the  DOA  was  5.  The  latest  version  of  TinyOS  [14]  supports 
variable  packet  size  during  transmission.  Under  this,  AIDA  can  achieve  higher  DOA  values. 

7.  Conclusion 

In  this  paper  we  introduce  AIDA,  an  adaptive  application  independent  data  aggregation  mechanism  for 
sensor  networks.  AIDA  performs  lossless  aggregation  by  concatenating  network  units  into  larger  payloads 
that  are  sent  to  the  MAC  layer  for  transmission.  Due  to  the  highly  dynamic  and  unpredictable  nature  of  wire¬ 
less  communication  in  sensor  networks,  a  novel  feedback-based  scheduling  scheme  is  proposed  to  dynamically 
adapt  to  changing  traffic  patterns  and  congestion  levels.  By  isolating  our  work  in  a  layer  that  sits  between  the 
networking  and  data-link  components  of  the  communication  stack,  AIDA  is  able  to  perform  such  aggregation 
without  incurring  the  costs  of  rewriting  components  to  upper  or  lower  layer  protocols.  Moreover,  very  signifi¬ 
cantly,  AIDA  is  a  value-added  compatible  solution  that  can  complement  and  augment  the  gain  of  application 
specific  data  aggregation  (ADDA)  schemes. 

In  our  experiments  we  evaluate  the  performance  gain  achieved  by  AIDA.  We  show  that  by  adaptively  con¬ 
figuring  our  aggregation  parameter  (DOA),  AIDA  only  introduces  a  small  header  overhead  (around  2  bytes  per 
network  unit  /  negative  overall  header  overhead)  while  reducing  end-to-end  delay  by  as  much  as  80%  and 
transmission  energy  by  30-50%  in  heavy  traffic  conditions.  As  shown  in  our  evaluation,  AIDA  running  in  the 
DYN  (fully  adaptive)  scheme  provides  the  best  overall  solution.  The  DYN  feedback  control  loop  dynamically 
tunes  our  DOA  threshold  and  sending  rate  to  optimize  aggregation  performance  under  varying  traffic  condi¬ 
tions  by  monitoring  queuing  delay  to  perform  data  aggregation  without  sacrificing  end-to-end  delay.  The 
MAC  control  overhead  is  also  reduced  to  allow  for  more  efficient  channel  scheduling. 

A  physical  implementation  of  AIDA  on  the  Berkeley  test  bed  provides  initial  evidence  of  the  savings  ob¬ 
tainable  by  an  application  independent  aggregation  scheme  and  pave  the  path  for  future  implementations  of 
our  adaptive  control  based  protocol. 
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